1. Field of the Invention
The present invention generally relates to the field of security enforcement on telecommunications terminals, either mobile or wired, and particularly to the enforcement of security of the application layer in telecommunications terminals having an open operating system, that allows the installation (and execution) of third-party software applications.
2. Description of Related Art
The diffusion and evolution of mobile telecommunications terminals (e.g., mobile phones of the last generation), in terms of computational power of the terminal, available communication bandwidth, availability of services and of software applications specifically designed for the telecommunications terminals, is widening the breadth of the services that the telecommunications terminals can make available to the users, and the modalities of accessing the telecommunications networks.
Nowadays, the availability of communication bandwidth and of computational power on mobile telecommunications terminals with an open operating system like Windows Mobile, Symbian, or SavaJe, has made it possible to offer new added-value services, and the adoption of “always on” connectivity profiles (i.e., the user of the telecommunications terminal is always connected to a telecommunications/data communications network, and can at any time access the offered services). Examples of these new services are the unified messaging (e-mail, instant messaging, Short Messaging Service—SMS—, Multimedia Messaging Service—MMS), secure access to enterprise's resources over IP (Internet Protocol) channels by the employees (for example by means of protected tunnels with protocols like TLS/SSL—Transport Security Layer/Secure Socket Layer—, IPsec—IP security—, L2TP—Layer 2 Tunnel Protocol—and the like), services of Digital Rights Management (DRM), access and exploitation of multimedia contents (based for example on the DVB-H—Digital Video Broadcasting-Handheld standard), access to enterprise's services and applications, and so on.
The availability of these powerful mobile telecommunications terminals is a great market opportunity, also considering the broad target of customers that can be reached by customized offers. However, such powerful terminals bring about security issues also in connection with the core business of the mobile telecommunications network operator. The mobile terminal is, under several respects, particularly vulnerable to software attacks: just to cite some examples, the mobile terminal is usually devoted to a personal use, it stores sensitive information (both of personal and of professional nature), it has a money credit associated with the SIM (Subscriber Identity Module), it stores information (like the IMSI—International Mobile Subscriber Identity—and the IMEI—International Mobile Equipment Identity) that allows an easy tracking of the user, it has access to wide communication bandwidth (e.g., GPRS/EDGE/UMTS), and it may implement different types of connectivity (like for example Wi-Fi, Bluetooth, IrDA—Infrared Device Application—, NFC—Near Field Communication, ZigBee).
Today, the security issues that involve mobile telecommunications terminals are mainly due to the sensitivity of the user (Social Engineering), and the diffusion of Trojan-type malware. A user of a mobile phone usually is less sensitive to security issues compared, for example, to a user of a Personal Computer (PC); this is in part due to the higher diffusion of mobile phones compared to PCs, and to the fact that a phone is generally perceived as a secure device, so users are not accustomed to consider that their mobile phones may be subject to software attacks.
Nowadays, the circulating malware is essentially of the Trojan type; thus, it rarely exploits the vulnerability of the software resident on the mobile terminal, rather it uses a “cover” application for installing on the terminal, after having obtained the user's authorization (and in this respect the low sensitivity of the user plays an important role), and then perpetrating the attacks for which it is designed (for example sending SMS to premium numbers, deleting user files and documents, illegally forwarding e-mail and other types of messages, replicating itself).
Several initiatives have been promoted for finding solutions to the increasing demand for higher security, driven in part by the diffusion of several malware applications. Some of the most important initiatives are the Microsoft Mobile-2-Market (http://msdn.microsoft.com/mobility/windowsmobile/partners/mobile2market/default.aspx), Symbian Signed (http://www.symbiansigned.com), OMTP (Open Mobile Terminal Platform) P6 Application Security Project (http://www.omtp.org), GSM-A MAS (Mobile Application Security) Project (http://www.gsmworld.com/using/security/mobile_application.shtml), Java MIDP (Mobile Information Device Profile) 2.0 (http://java.sun.com/products/midp/index.jsp).
In general, all the known initiatives are based on a same model, hereinafter referred to as the “trust model”, which generally defines two macro-categories of software applications that can run on a mobile telecommunications terminal: trusted applications and non-trusted applications.
Non-trusted applications are digitally unsigned applications (or application digitally signed by untrusted Certification Authorities—CAs) whose genuinity cannot be assessed on the terminal when they are installed and/or executed; these applications are thus a potential source of attacks to the terminal, because there is no information about them and it is not possible to perform any check. For these reasons, non-trusted applications are allowed to access only a limited subset of resources of the telecommunications terminal, i.e. of APIs (Application Program Interfaces), exposed by the operating system, namely APIs that are not considered dangerous.
Trusted applications are instead digitally signed (by trusted CAs), and are allowed to access a wider set of exposed APIs. In particular, the APIs exposed by the operating system are grouped in different classes, according to a criterion of criticality of the accessed resources. The trusted, digitally signed applications are mapped onto a certain security level based on the CA that issued the digital certificate with which the application has been signed. Different security levels are defined, corresponding to different “root certificates”: an application is certified with respect to a certificate chain which refers to one of the root certificates present on the terminal. The security level to be assigned to the application is determined on the basis of the security level assigned to the root certificate used during the phase of verification. The security level assigned to the application determines the set of resources that the application can access, and the way the application can interact with them. In some cases, an application having been assigned a certain security level does not gain access to all the resources specified for that level, but only to those specified by the software vendor during the certification process.
The use of the digital signature mechanism further allows implementing an application revocation mechanism, when the applications are compromised or violate specific security policies. For example, in case of availability of connectivity, the mobile terminal, before installing and/or executing an application, may ascertain whether the considered application has been revoked; this may be done by downloading and checking a Certificate Revocation List (CRL), or exploiting protocols like the Online Certificate Status Protocol (OCSP), so as to get an immediate response about the validity of the certificate tied to the signing key, and therefore of the related signed application.
An example of implementation of the trust model can be found in EP-A-1361527 in which a method is described for loading an application into a device, and generally for downloading applications into portable devices, typically mobile telephones. The method includes the steps of: downloading the application with a signature to the device; coupling the signature of the application to a predefined attribute certificate stored in the device; and installing the application together with said attribute certificate. Preferably, the signature of the application is coupled to a root certificate which in turn is linking the application to a predefined attribute certificate.
Another example of implementation of the trust model can be found in WO 2006/017757 in which a method and an apparatus are disclosed for providing enhanced security using service provider authentication. In addition to authenticating an application signature against a root certificate stored on the network node, a first carrier identification associated with the application is compared to a second carrier identification. If the first and second carrier identifications match, then the application can be assigned to a trusted protection domain and granted permissions which provide privileged access to the network node. For example, the application can be granted permission to be installed and/or executed on the network node. Otherwise the application can be denied privileged access. Accordingly, a carriers applications will be only installed onto network nodes that are intended recipients of the applications.
Still another example of implementation of the trust model can be found in US 2005/03398 in which a single machine has entities running in an untrusted environment and entities running in a trusted environment, the trustworthiness of the entities in the trusted environment is projected to the entities in the untrusted environment. This is applicable, for example, to Microsoft's Next Generation Secure Computing Base (NGSCB), where a regular operating system (e.g., the Windows operating system) hosts a secure operating system (e.g., the nexus).